feat(discord): bot turn limits (soft + hard) for bot-to-bot loops#467
Merged
thepagent merged 2 commits intoopenabdev:mainfrom Apr 19, 2026
Merged
feat(discord): bot turn limits (soft + hard) for bot-to-bot loops#467thepagent merged 2 commits intoopenabdev:mainfrom
thepagent merged 2 commits intoopenabdev:mainfrom
Conversation
Instead of fetching thread history to detect other bots on every unmentioned message, detect multi-bot threads eagerly from msg.author: when a bot message arrives in a thread, cache multibot_threads immediately — zero API calls needed. This eliminates per-message fetches in MultibotMentions mode for single-bot threads (which would never find other bots but fetched every time to check). - Add early detection before gating: msg.author.bot → cache multibot - Simplify bot_participated_in_thread: cached_involved → return immediately with cached_multibot, no MultibotMentions special-casing Builds on openabdev#464
github-actions
bot
added
the
closing-soon
|
All PRs must reference a prior Discord discussion to ensure community alignment before implementation. Please edit the PR description to include a link like: This PR will be automatically closed in 3 days if the link is not added. |
chaodu-agent
force-pushed
the
feat/bot-turn-limits
branch
2 times, most recently
from
59df8f2 to
2191e8b
Compare
Add two-layer protection against runaway bot-to-bot mention loops: - Soft limit (max_bot_turns, configurable, default 10): consecutive bot turns without human intervention. Sends warning and stops. Human message resets the counter. - Hard limit (HARD_BOT_TURN_LIMIT = 100, not configurable): absolute per-thread cap. Permanently stops bot-to-bot conversation. Both limits send a visible message to the thread so humans and bots know why the conversation stopped. This addresses the gap where MAX_CONSECUTIVE_BOT_TURNS is ineffective for interleaved bot-to-bot mentions (counter resets when own message breaks the take_while chain). Closes openabdev#466
chaodu-agent
force-pushed
the
feat/bot-turn-limits
branch
from
2191e8b to
cd76d44
Compare
thepagent
approved these changes
Apr 19, 2026
chaodu-agent
added a commit
to chaodu-agent/openab
that referenced
this pull request
Apr 19, 2026
Human intervention should reset both soft and hard counters. Previously hard counter never reset, meaning a thread could be permanently locked out of bot-to-bot conversation even with human oversight. Builds on openabdev#467
chaodu-agent
added a commit
to chaodu-agent/openab
that referenced
this pull request
Apr 19, 2026
Human intervention should reset both soft and hard counters. Previously hard counter never reset, meaning a thread could be permanently locked out of bot-to-bot conversation even with human oversight. Builds on openabdev#467
chaodu-agent
added a commit
to chaodu-agent/openab
that referenced
this pull request
Apr 19, 2026
Human intervention should reset both soft and hard counters.
Previously hard counter never reset, meaning a thread could be
permanently locked out of bot-to-bot conversation even with
human oversight.
Extract BotTurnTracker struct for testability:
- on_bot_message() returns TurnResult::{Ok, SoftLimit, HardLimit}
- on_human_message() resets both counters
- 8 unit tests covering all edge cases
Builds on openabdev#467
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #466
Add two-layer protection against runaway bot-to-bot mention loops. The existing
MAX_CONSECUTIVE_BOT_TURNSis ineffective when bots interleave messages (each bot's own reply breaks thetake_whilechain, so the counter never reaches the cap).Design
Soft limit (
max_bot_turns, configurable)max_bot_turnsin[discord]configHard limit (
HARD_BOT_TURN_LIMIT = 100, not configurable)How it works
The difference: soft is configurable (default 20), hard is fixed at 100. If someone sets
max_bot_turns = 100or higher, the hard limit is the safety net.Changes (+63/-0)
src/config.rs: addmax_bot_turnsfield (default 20) toDiscordConfigsrc/discord.rs: addHARD_BOT_TURN_LIMIT = 100const,bot_turn_countsper-thread(soft, hard)counters, counting + throttle logic (placed after all gating)src/main.rs: initializebot_turn_countsandmax_bot_turnsdocs/discord.md: document bot turn limitsWhy not fix
MAX_CONSECUTIVE_BOT_TURNS?The existing check counts consecutive messages from other bots using
take_while. When Bot A and Bot B alternate, each bot's own reply breaks the chain — the counter never exceeds 1. The fundamental issue is the counting method, not the cap value. Our approach counts all bot turns regardless of interleaving.Related
multibot-mentionsmode for allow_user_messages #464 —multibot-mentionsmode